This guide identifies features and functionality added or modified between software releases 7.x and 8.x. All features listed in this guide are split up according to the release that it was initially supported in.
It is now possible to configure the transmit clock source, as either Building Integrated Timing Supply (BITS) or line-timing, for application services using SDH or SONET over the Optical line card or the Channelized line card.
BITS-timing provides the transmit timing source, using Stratum 3 compliant BITS modules resident on either the SPIO with a BITS BNC interface or the SPIO with a BITS 3-pin interface. Line-timing recovers the receive timing from an external clock source via a port on an Optical or Channelized line card. It is possible to configure both clock sources, so that one timing source backs up the other.
To configure and manage this feature, a new CLI configuration sub-mode has been added to the Global configuration mode - the BITS Port Configuration Mode, details in the Command Line Interface Reference, includes the following new commands:
Configuration of this clock source is explained in Configuring Transmit Timing Source in the System Administration Guide.
The CDR files can be pushed from the chassis to the configured external storage server periodically using the SFTP protocol. This functionality is supported both on the ST16 and ST40 platforms.
With the PUSH transfer mode, the external storage server URL to which the CDR files need to be transferred should be specified. The configuration allows a primary and a secondary server to be configured. Configuring the secondary server is optional. Whenever a file transfer to the primary server fails for four consecutive times, the files will be transferred to the secondary server. The transfer will switch back to the original primary server when:
|
l
|
Transfer interval: A time interval, in seconds, after which the CDRs are pushed to the configured IP periodically. All the files that are completed before the PUSH timer expires are pushed.
|
|
l
|
Remove file after transfer: An option to keep or remove the CDR files on the hard disk after they are transferred to the external storage server successfully.
|
This support added to configure traffic from the specified DHCP service bind address to use the MPLS labels. This support also provides the configuration to define the next-hop gateway address.
To configure and manage this feature, a new optional keyword nexthop-forwarding-address nexthop_ip_address with other options has been added to the bind address ip_address command in DHCP Configuration mode in the Command Line Interface Reference.
Configuration of this support is explained in Multi Protocol Label Switching chapter in the System Enhanced Feature Configuration Guide.
A new four port Gigabit Ethernet line card (usually referred to as the Quad Gig-E Line Card or QGLC) has been introduced for the ST40 platform only.
Using hot-swappable small form-factor pluggable (SFP) modules, the card can support either 1000Base-SX, 1000base-LX and 1000Base-T configurations. Note that all four ports must be of one type; there can be no mix-and-matching interfaces.
QGLCs can be installed in chassis slots 17 through 23, 26 through 39, and 42 through 48. These cards should always be installed directly behind their respective PSCs, but are not required to be placed behind any redundant PSCs (those operating in Standby mode). Cards inserted in pairs behind an active PSC offer 1:1 redundancy and automatic failover.
It has four ports instead of one which is less expensive than having to buy more than one line card if you need more than one port. With more ports the QGLC line card increases aggregate throughput to external devices (up to 2.8 Gbps depending on call model).
The QGLC uses a new generation of Fixed Programmable Gate Array (FPGA).The new FPGA allows the Star Channel (the 140Gbps internal bus) to be used for firmware upgrades. This dramatically improves the time it takes upgrade the card firmware for future enhancements.
For more information, see the “Hardware Platform Overview” chapter of the Hardware Installation and Administration Guide.
When storing CDR files on the SMC HDD, at first they are stored on the RAMFS before being moved to the HDD. The files can then be off-loaded via FTP or SFTP to an external server (such as the L-ESS or the GSS) or billing system.
When using the HDD for EDR/UDR storage, EDR/UDR files are transferred from RAMFS on the PSC card to the HDD on the SMC card. The HDD may also be used to store any data that needs to be backed up.
The secondary SMC card also contains an HDD, which serves as a redundant and becomes active during an SMC failover. The HDD on the secondary is mirrored to the HDD on the primary in order to avoid any data loss. Basically, the drives are raid-1 redundant.
HDD support is only available on the ST40 platform, so in the case of an “ST16” or an “ST40 without a HDD”, a card failover results in a loss of CDR files. In the case of card failover on an “ST40 with a HDD”, the new Active SMC starts pushing the files. Any files that are left in the middle of the transfer will be transferred again.
If the hard disk drive (HDD) is used for CDR storage, with the monitor protocol CLI command in the Exec Mode, the CDR option (29) must be used and not GTPP option (27).
Provides a means of aggregating or trunking from one to four ports on a redundant pair of Quad Gig-E line cards (QGLC) in order to guarantee a file transmission is sent serially over one link until it is finished downloading. Each PSC and its associated QGLC(s) forms a system and negotiates with an aggregation on a remote port using Link Aggregation Configuration Protocol (LACP).
This release includes a number of new and/or modified commands and Web Element Manager application functions. These are detailed in this guide.
When AAA proxy is configured to write CDRs into the SMC hard disk, there are chances of duplicate records being written to the file if the AAA proxy crashes after writing the file to the RAM disk and before sending an ACK to AAAMgr. To prevent this, a mechanism is now in place for the AAA proxy to avoid writing duplicate records when AAAMgr retransmits the request later.
The Starent Networks now provides IPMS (Intelligent Packet Monitoring System) solution for operators to analyze and investigate call related events on the Starent Networks Access Gateways (AGWs) like PDIF, PDSN, GGSN, SGSN, etc.
The Intelligent Packet Monitoring System application provides the functions to assist operators to analyze and investigate call related events at a later point of time. When IPMS is enabled for a product, the AGW sends a copy of call control events as well as system event packets (IKE, Proxy-MIP, RADIUS, DIAMETER etc.) with some additional information to an external server for every call as part of normal system processing. The external server stores the received call control events and system event packets for later analysis.
The IPMS client service can be enabled on AGW through ipms command in Context Configuration Mode and IPMS servers can be configured in IPMS Client Configuration Mode on an AGW. For more information on hardware and other requirements for this application support, refer IPMS Installation and Administration Guide.
The Intelligent Packet Monitoring System solution is a separate product and must be purchased separately. Contact your designated sales or service representative.
This feature enables initiation of new L2TP create tunnel request to same LNS address based on the value of attribute “Tunnel-Server-Auth-ID” in Access-Accept message received from AAA server. This value is treated as a key to identify tunnel. Thus, effectively, this result in multiple L2TP tunnels based on the value of attribute received from AAA server by a LAC. This value of attribute is treated as a key to identify tunnel.
In earlier implementation, LAC chooses to create a new tunnel between LAC and LNS pair only when existing tunnel has reached its full capacity of allowed L2TP sessions per tunnel. There was no provision to the further segregation of the traffic between LAC and LNS.
New CLI command tunnel selection-key { tunnel-server-auth-id | none } is added in LAC service configuration mode to support this feature. This command will provide facility to create new tunnel on the basis of value of domain attribute received from AAA server before reaching the session capacity on existing tunnels.
The Packet Services Card 2 (PSC2) is the next-generation packet forwarding card for the ST40. The PSC2 provides increased aggregate throughput and performance, and a higher number of subscriber sessions.
The PSC2 has been enhanced with a faster network processor unit, featuring two quad-core Intel x86 2.5Ghz CPUs, 32 GB of RAM. The PSC2 provides 2 to 2.7 times the data throughput of the original PSC, and the switch fabric interface has been doubled.
A second-generation data transport fixed programmable gate array (DT2 FPGA, abbreviated as DT2) connects the PSC2’s NPU bus to the switch fabric interface. The FPGA also provides a bypass path between the line card or Redundancy Crossbar Card (RCC) and the switch fabric for ATM traffic. Traffic from the line cards or the RCC is received over the FPGA’s serial links and is sent to the NPU on its switch fabric interface. The traffic destined for the line cards or RCC is diverted from the NPU interface and sent over the serial links.
DT2 FPGA also connects to the control processors subsystem via a PCI-E bus. The PCI-E interface allows the control processors to perform register accesses to the FPGA and some components attached to it, and also allows DMA operations between the NPU and the control processors’ memory. A statistics engine is provided in the FPGA. Two reduced latency DRAM (RLDRAM) chips attached to the FPGA provide 64MB of storage for counters.
The PSC2 has a 2.5 G/bps-based security processor that provides the highest performance for cryptographic acceleration of next-generation IP Security (IPsec), Secure Sockets Layer (SSL) and wireless LAN/WAN security applications with the latest security algorithms.
It is not recommended that PSC2s are mixed with PSCs, since this prevents the PSC2 from operating at its full potential. Due to the different processor speeds and memory configurations, the PSC2 cannot be combined in a chassis with the original PSC 16 GB.
For more information, see the “Hardware Platform Overview” chapter of the Hardware Installation and Administration Guide.
The 10 Gigabit Ethernet Line Card is commonly referred to as the XGLC. The XGLC supports higher speed connections to packet core equipment, increases effective throughput between the ST40 and the packet core network, and reduces the number of physical ports needed on the ST40.
The XGLC is a full-height line card. To install an XGLC, you must remove the half-height card guide in the rear of the chassis. Once installed, use only the upper slot number to refer to or configure the XGLC. XGLCs can be installed in chassis slots 17 through 23 and 26 through 32. These cards should always be installed directly behind their respective PSCs or PSC2s, but they are not required behind any redundant PSCs or PSC2s (those operating in Standby mode).
The one-port XGLC supports the IEEE 802.3-2005 revision which defines full duplex operation of 10 Gigabit Ethernet.
The XGLC use a Small Form Factor Pluggable (SPF+) module. The modules support one of two media types: 10GBASE-SR (Short Reach) 850nm, 300m over Multimode (MMF), or 10GBASE-LR (Long Reach) 1310nm, 10km over Single Mode (SMF).
The XGLC is configured and monitored via the System Management Card (SMC) over the system’s control bus. Both SMCs must be active to maintain maximum forwarding rates.
A feature of the higher speed line cards (XGLC and the Quad Gigabit Ethernet Line Card or QGLC), is the ability to use the Star Channel if the firmware needs to be upgraded. The Star Channel is a 2x140Gbps redundancy bus between the PSC and the line card that allows a faster download. Another way to perform a firmware upgrade is via the System Management Bus, with 1 Mbps throughput, which connects the SMC to every card in the system.
For more information, see the “Hardware Platform Overview” chapter of the Hardware Installation and Administration Guide.
The WiMAX CPE modem is used in Fixed/Nomadic application to support multiple IP hosts and it share the singles WiMAX airlink to connect to the WiMAX IP network.
This feature is a effective solution for Small Office/Home Office (SOHO) users to provide multiple station connectivity through one airlink.
The WiMAX ASNGW allows each WiMAX MS (identified by its 6-byte MSID) to be assigned with a single IP address. IP accounting is maintained for the IP address.
The ASNGW is responsible for managing the allocation and freeing of IP address, to manage the data path for it and to maintain accounting of data packets for it.
For more information on this feature, refer to the Multi-host Support section in ASN GW Overview chapter.
In the URL Blacklisted Content Filtering solution, all HTTP/WAP requests from subscribers are inspected in order to determine the requested destination URLs/URIs. Each URL/URI is then matched against a database of blacklisted URLs, if there is a match, one fixed action—discard, redirect, or terminate—is taken. If the requested URL/URI is not present in the blacklist in its exact, literal form then the request is passed on as usual. This content filtering solution can either be applied to all subscribers or none. Typical cases include applying a blacklisted database of child porn URLs to all subscribers so that they are not inadvertently exposed to such content.
For more information, see the Content Filtering Services Administration Guide.
In support for grouped rule categories, a Group of Ruledefs Configuration Mode has been included within the Active Charging Service Mode. This enables grouping rules into categories, so that charging systems can base the charging policy on the category. A group of ruledefs may contain optimizable ruledefs. If all the ruledefs in a group of ruledefs can be optimized, and if the group is included in a rulebase that has optimization turned on, then the group will be optimized.
Readdressing of packets based on the destination IP address of the packets is now supported. This enables redirecting unknown gateway traffic to known/trusted gateways.
The IP Readdressing is configured in the flow action defined in a charging action. IP readdressing works for traffic that matches particular ruledef and hence the charging action. IP readdressing is applicable to both uplink and downlink traffic. In the Active Charging Subsystem, uplink packets are modified after packet inspection, rule matching, etc., where the destination IP/port is determined, and replaced with the readdress IP/port just before they are sent out. Downlink packets (containing the readdressed IP/port) are modified as soon as they are received, before the packet inspection, where the source IP/port is replaced with the original server IP/port number.
For one flow from an MS, if one packet is re-addressed, then all the packets in that flow will be re-addressed to the same server. Features like DPI, rule-matching, etc. remain unaffected. Each IP address + port combination will be defined as a ruledef.
In case of IP fragmentation, packets with successful IP reassembly will be readdressed. However, IP fragmentation failure packets will not be re-addressed.
In support for the Network Controlled QoS (NCQoS) feature providing control of QoS for subscriber from network element side; i.e. GGSN, a Packet Filter Configuration Mode has been included within the Active Charging Service mode. This mode enables configuring a packet filter’s parameters.
Corrected DCCA Behavior upon Receipt of Charging-Rule-Base-Name AVP
The “Charging-Rule-Base-Name” AVP (code: 1004) is sent in CCA messages from the Gy server to set the rulebase. The rulebase that comes in this AVP must already be configured in the system. In v7.0, ACSMgr checks for the rulebase, and if it is not present discards the message, a CCR-T is not sent. In v7.1 and later, if the rulebase is not present the message is rejected, and a CCR-T is sent with DIAMETER_BAD_ANSWER as the termination cause.
ECS now supports pipelining of up to 32 HTTP requests on the same TCP connection. Pipeline overflow requests are not analyzed. Such overflow requests are treated as http-error. The billing system, based on this information, decides to charge or not charge, or refund the subscriber accordingly.
In the Optimized mode, ACS Managers (ACSMgrs) are merged with Session Manager (SessMgr), and enhanced charging facilities run as part of the SessMgr. Also, the controller functionality is unified, i.e. the ACS Controller (ACSCtrl) is merged with the Session Controller (SessCtrl).
In the Optimized mode, recovery/reconciliation of ACSCtrl with ACSMgrs is coupled with SessCtrl recovery. I.e., SessCtrl handles recovery of enhanced charging specific configuration. And, reconciliation of ACSCtrl vis-à-vis SRDB tasks is added to SessCtrl reconciliation. SRDB tasks hold the third-party database, which is used for static category-based content-filtering. In Release 8.0, these SRDB tasks are handled by ACSCtrl. In Release 8.1 the SessCtrl controls these SRDB tasks.
The Optimized mode benefits the in-line services that run as part of ECS, i.e. Firewall and Peer-to-Peer with performance improvement.
IMPORTANT: By default, on installing Release 8.1, the system comes up with ECS in non-optimized mode. If the ECS mode is changed from the default (non-optimized) mode to the Optimized mode, or vice-versa, the system must be rebooted for the change to take effect.IMPORTANT: In UMTS networks, if ECS is configured in the Optimized mode, secondary PDP context traffic does not undergo ECS processing.EDR Generation in Flow-end and Transaction Complete Scenarios with sn-volume Fields
In this release sn-volume-amt counters will be re-initialized only when the fields are populated in EDRs. For example, consider the following two EDR formats:
Previously, if edr2 was generated, even though sn-volume-amt fields are not populated, sn-volume-amt counters (uplink bytes, uplink packets, downlink bytes, downlink packets) were re-initialized. So the total volume reflected by EDRs in sn-volume-amt counters was less than the actual count.
In this release, sn-volume-amt counters will be re-initialized only if these fields are populated in the EDRs. Now, if edr2 is generated, these counters will not be re-initialized. These will be re-initialized only when edr1 is generated.
Also, note that only those counters will be re-initialized which are populated in EDR. For example, in the following EDR format:
If edr3 is generated, only uplink bytes and downlink bytes counters will be re-initialized and uplink packets and downlink packets will contain the previous values till these fields are populated (say when edr1 is generated).
The origin host encoding sent in all Diameter messages from the system in the <instance>-<facility-name>.<origin-host> format has changed.
In the non-optimized mode, it is encoded as 001-acsmgr.starentnetworks.com.
In the optimized mode, it is encoded as 001-sessmgr.starentnetworks.com.
|
l
|
In the optimized mode, the number of connections will be <number of PSC> x 7 SessMgrs.
|
In the Rel. 7 Gx implementation, any Abort-Session-Request (ASR) received by the PCEF/BBERF will be treated as an unsupported command. In response, an Abort-Session-Answer (ASA) is sent with DIAMETER_COMMAND_UNSUPPORTED (3001).
In the v8.0 Rel. 7 Gx implementation, when a charging rule definition is sent from PCRF without the Precedence AVP, the default precedence value (255) is populated. Existing precedence of the rule definition changes to the default value (255) even when there is no Precedence AVP in the update.
Now, if the Precedence AVP is missing in the new charging rule definition sent from the PCRF, the default precedence value (255) is not populated, and the charging rule definition is rejected. In the update case, if the Precedence AVP is missing, it is not updated with the default precedence value (255), and the charging rule definition is not rejected. The existing precedence is used.
ECS now supports pipelining of up to 32 HTTP requests on the same TCP connection. Pipeline overflow requests are not analyzed. Such overflow requests are treated as http-error. The billing system, based on this information, decides to charge or not charge, or refund the subscriber accordingly.
Unsupported protocol in the flow description is considered as failure and is no longer set with IP as default protocol. In the create case, the rule definition is rejected when this failure happens. In the update case, the existing rule definition is removed when the failure happens.
This section contains information on features that pertain to the Local-External Storage Server (L-ESS) and Remote (Long Term)-External Storage Server (R-ESS).
This section contains information on features that pertain to the Local-External Storage Server (L-ESS) and Remote (Long Term)-External Storage Server (R-ESS).
R-ESS introduces new configurables to selectively discard the insignificant UDRS in the database based on a threshold limit in the form of number of total bytes. The statistics of the discarded UDRs will be displayed in Summary Report. Discarding the insignificant UDRs will result in the reduction of the number of records in the database and improvement of the R-ESS reporting performance.
The R-ESS extends its support to include yet another configurable that is set accordingly to enable the collection of parsing statistics report.
This functionality allows the user to select multiple content types from GUI as well as CLI and enables the R-ESS to generate Threshold Content Type and/or Top N Content Type reports based on the selected types. This feature further enables the R-ESS to specify a combined threshold for the selected content types and view the list of users who have used the most amount of traffic for the content types.
The L-ESS application extends its support to include some new configurables that are set appropriately to pull the xDR files from ST-series platform and push the files to configured destinations. When this functionality is enabled, L-ESS will start the pull process and file transfer process simultaneously or separately based on the configurations. The L-ESS is configured in such a way that the files are accepted from ST-series platform and then pushed to a central location at L-ESS. The L-ESS pushes the files further to the destinations. The file transfer process will automatically detect the number of hosts and whether they are willing to push EDR / UDR files to L-ESS by detecting the directories present below the configured base path.
The L-ESS extends its support to include some new parameters in the configuration file, allowing the user to configure up to a maximum of four SNMP destinations for the traps to be forwarded.
Also, a script ‘addhosts.sh’ is modified for addition and removal of Starent and SNMP Manager hosts dynamically. This script is now menu driven and provides option for adding and removing these hosts.
For more information, see the ESS Installation and Administration Guide.
The integration of Stateful Firewall and Enhanced Charging Service in this release has resulted in the following changes:
|
l
|
ACS Firewall Ruledef Configuration Mode—This new mode is available under the ACS Configuration mode. Firewall rule definitions are configured in this mode.
|
|
l
|
Firewall Rulebase Configuration Mode—This mode is no longer available. Both ACS and Firewall ruledefs are now included in ACS rulebases.
|
|
l
|
Firewall Host Pool Configuration Mode—Moved under the ACS Configuration Mode, and renamed to ACS Host Pool Configuration Mode.
|
|
l
|
Firewall IMSI Pool Configuration Mode—Moved under the ACS Configuration Mode, and renamed to ACS IMSI Pool Configuration Mode.
|
|
l
|
Firewall Port Map Configuration Mode—Moved under the ACS Configuration Mode, and renamed to ACS Port Map Configuration Mode.
|
A new Firewall Ruledef Configuration mode is available in Release 8.0 under the ACS Configuration mode. Firewall rule definitions are configured in this mode.
The Host Pool, IMSI Pool, and Port Map configuration modes, which were specific to Stateful Firewall configuration, are moved under the ACS Configuration mode for Release 8.0.
With this release, if a Stateful Firewall license is installed on the system, Active Charging Services (ACS) will also be enabled. A separate ECSv2 license will not be required to enable ACS. However, if an ECSv2 license is installed on the system, a Firewall license is still required to enable Firewall.
The NAT feature is used to translate non-routable private IP addresses to routable public IP address(es) from a pool of public IP addresses that have been assigned for NAT. This conserves on the number of public IP addresses required to communicate with external networks, and ensures security as the IP address scheme for the internal network is masked from external hosts, and each outgoing and incoming packet is translated. NAT can be used to perform address translation for simple-IP and mobile-IP.
NAT can be selectively applied to different flows (5 tuple connections) originating from the subscribers based on the flows' L3/L4 characteristics (Source-IP, Source-Port, Destination-IP, Destination-Port, and Protocol). Some flows can be selectively marked for “no NAT” processing based on the flows' L3/L4 characteristics.
NAT works by inspecting both incoming and outgoing IP datagrams and, as needed, modifying the source IP address and port number in the IP header to reflect the configured NAT address mapping for outgoing datagrams. The reverse NAT translations is done for incoming datagrams.
For more information, see the Personal Stateful Firewall Administration Guide.
In StarOS 8.1, Stateful Firewall releases for CDMA networks use rulebase-based configurations. Whereas, while earlier releases of Stateful Firewall and NAT for UMTS networks used rulebase-based configurations, the current releases use policy-based configurations.
In the Policy-based Firewall and NAT implementation, Firewall-and-NAT policies are configured in the ACS Firewall-and-NAT Policy Configuration Mode. Each policy contains a set of ruledefs and the firewall/NAT configurations. Multiple such policies can be configured, however, only one policy is applied to a subscriber at any point of time.
The policy used for a subscriber can be changed either from the CLI, or by dynamic update of policy name in Diameter and RADIUS messages. In both cases NAT status on the active call remains unchanged.
For more information, see the Personal Stateful Firewall Administration Guide.
When upgrading from a pre-8.1 release to 8.1, Firewall must be enabled in the rulebase or the Firewall-and-NAT policy as shown in the following configuration examples.
Starent Networks GGSN now supports Multimedia Broadcast and Multicast Service. The MBMS is an IP datacast type of service in GSM and UMTS cellular network. It eliminates unnecessary replication of data on UMTS wireless networks by transmitting a single stream of data to multiple users. By delivering a single, unidirectional data stream to many subscribers, MBMS makes more efficient use of wireless network resources than traditional point to point connections.
MBMS is a solution for transferring light video and audio clips and also a suitable method for mass communications. MBMS functionality on the system is provided by an existing GGSN and/or SGSN service license. In the absence of a valid license, the system functions as a standard unicast GGSN. When a GGSN is functioning in a MBMS environment, it supports Gmb protocol interface with Broadcast/Multicast Service Center (BM-SC) for messaging.
Figure 1-2 shows the reference architecture of MBMS service in UMTS network.
For more details on configuration of this service, refer Multimedia Broadcast and Multicast Service chapter in System Enhanced Feature Configuration Guide.
This feature provides control of QoS for subscriber from network element side; i.e. GGSN. It uses bearer control mode and Active Charging Services parameters to provide packet filtering and other quality class identifier related configurations.
Network-controlled QoS is the method by which the QoS for a PDP context (primary or secondary) is updated on the request of the GGSN through Network Requested Update PDP Context (NRUPC) message. It can also activate a new secondary PDP context on Network Requested Secondary PDP Context Activation (NRSPCA) message from the GGSN.
For more details on configuration of this service, refer Dynamic QoS Renegotiation chapter in System Enhanced Feature Configuration Guide.
This is an enhanced feature is a traffic rate limiting method similar to Traffic Policing, however, shaping provides a buffer facility for packets exceeding the configured limit. Once the packets exceed the data-rate, the packets queue inside the buffer to be delivered at a later time.
The bandwidth enforcement can be done in the downlink and the uplink directions independently. If there is no more buffer space available for subscriber data, the system can be configured to either drop the packets or keep them for the next scheduled traffic session.
For details on configuring this service, refer to the Traffic Policing and Shaping chapter in the System Enhanced Feature Configuration Guide.
Direct tunnel improves the user experience (e.g. expedited web page delivery, reduced round trip delay for conversational services, etc.) by eliminating SGSN tunnel ‘switching’ latency from the user plane. An additional advantage of Direct Tunnel from an operational and capital expenditure perspective is that direct tunnel optimizes the usage of user plane resources by removing the requirement for user plane processing on the SGSN.
The Direct Tunnel architecture allows the establishment of a direct user plane tunnel between the RAN and the GGSN, bypassing the SGSN. The SGSN continues to handle the control plane signalling and typical makes the decision to establish Direct Tunnel at PDP Context Activation. A Direct Tunnel is achieved at PDP context activation by the SGSN establishing a user plane (GTP-U) tunnel directly between RNC and GGSN (using an Update PDP Context Request towards the GGSN).
A major consequence of deploying Direct Tunnel is that it produces a significant increase in control plane load on both the SGSN and GGSN components of the packet core. It is therefore of paramount importance to a wireless operator to ensure that the deployed GGSNs are capable of handling the additional control plane loads introduced of part of Direct Tunnel deployment. The Starent GGSN and SGSN offers massive control plane transaction capabilities, ensuring system control plane capacity will not be a capacity limiting factor once Direct Tunnel is deployed.
DNS query and DNS resolve procedure on system is now modified to support DNS parameters from LNS.
The system will supports configuration of DNS at the Context level in Context configuration with ip name-server command as well as at the APN level in APN configuration mode with dns and ipv6 dns commands, or it can be received from AAA server.
When DNS is requested in PCO configuration, the following preference will be followed for DNS value:
The same preference would be applicable for the NBNS servers to be negotiated via ICPC with the LNS.
CCR (T) Sent after Receiving “Diameter-Credit-Limit-Reached” at Message Level in CCA (I) after Upgrade to v8.0
In the earlier releases, in this scenario, the system did not send a CCR (T) with DIAMETER-ADMINISTRATIVE result-code; the system silently discarded the answer and terminated the session.
In v8.0, the system sends a CCR (T) with DIAMETER_ADMINISTRATIVE as the result-code. System failure-handling can be set to “retry & terminate” (default) or “terminate”.
A hard disk has been introduced in the ST40 platform to add storage capability. When storing CDR files on the SMC hard disk, first they are stored on RAMFS before they are moved to the hard disk and then they can be off-loaded via ftp or sftp to an external server (such as the L-ESS or the GSS) or billing system. For additional support information, see Hard Disk Support on SMC Card in ST40 Platform.
|
l
|
Use the new command gtpp storage-server local file {local | remote } command in GTPP Group Configuration Mode to configure and enable hard disk usage.
|
|
l
|
Use the new show/clear commands { show | clear } gtpp storage-server local file { counter | statistics } in the Exec Mode to monitor/clear the file counters and statistics on the hard disk.
|
|
l
|
Use the new gtpp ram-disk-limit and gtpp compression-process commands in the Global Configuration Mode to allocate RAM for files and the number of compression process to support the hard disk functionality.
|
ST40 platforms now supports NPU assisted processing of MBMS data packets and relieves the Session Manager to provide better performance. Currently with NPU assisted data processing ST40 can support 225 SGSNs per MBMS Bearer Service for downlink of MBMS data. Earlier it was limited to 15.
This enhancement is not applicable to ST16 platforms and a maximum of 15 downlink SGSNs per MBMS Bearer service are supported.
For details about this new enhancement, refer MBMS Service Configuration chapter of the System Enhanced Feature Configuration Guide.
For IMS deployment in GPRS/UMTS networks the system uses Rel. 7 Gx interface for policy-based admission control support and flow-based charging. The Rel. 7 Gx interface supports enforcing policy control features like gating, bandwidth limiting, etc., and also supports flow-based charging. This is accomplished via dynamically provisioned Policy Control and Charging (PCC) rules. These PCC rules are used to identify service data flows and do charging. Other parameters associated with the rules are used to enforce policy control.
The PCC architecture allows operators to perform service-based QoS policy, and flow-based charging control. In the PCC architecture, this is accomplished mainly by the Policy and Charging Enforcement Function (PCEF)/Starent Networks GGSN and the Policy and Charging Rules Function (PCRF).
For more information see the Gx Interface Support chapter of the System Enhanced Feature Configuration Guide.
Quad Gig-E Line Card (QGLC) & Link Aggregation
The GGSN now supports the four-port gigabit-Ethernet line card - QGLC. This card will enable the GGSN to utilize standard-compliant link aggregation. For additional feature information, see QGLC and Link Aggregation feature descriptions in the Common Features in Release 8.0 section of this chapter.
For details about this new line card, see the Hardware Platform Overview chapter of the Hardware Installation and Administration Guide.
The GGSN system now drops uplink/downlink packets when SGSN sends Update PDP Context request for QOS change with maximum bit rate (MBR) as zero for conversational/streaming class of services. This is the default behavior and no configuration required.
Regulatory requirements in EU require GGSN to send CDRs to both GSS and CGF while GSS being the billing interface. CDRs sent to CGF should not be buffered and retried in the event the CGF goes down and later comes back. To support this, a secondary GTPP group can be configured under APN, and SessMgr duplicates CDRs to both GTPP groups with a CLI to enable/disable archiving in GTPP group.
This feature enables configuring a secondary GTPP group in the APN. If the secondary group is configured, when the accounting information is generated, it will also be duplicated to the specified secondary group. This can serve as a backup of the accounting information by sending one record to a GSS server and the other to a CGF server or both to either the GSS/CGF.
This enables/disables archiving for CGF only. When enabled, once the server is detected to be down, the request sent to the CGF is purged. Also, the requests generated for the period when the server is down is purged. If a secondary CGF is configured, new requests are directed to the secondary CGF while the requests retried with the primary are purged. By default this is disabled.
This new support provides facility to configure the transport layer protocol for Ga interface on AGW (GSNs). Now operator can run Ga interface on TCP as well.
Currently Ga interface between AGW and GTPP server was supported with UDP as default transport layer protocol. To provide connection-oriented session on Ga interface, new configurable feature is to select between UDP and TCP as transport layer protocol for Ga interface. For more information refer gtpp transport-layer command in GTPP Server Group Configuration Mode Commands chapter of Command Line Interface Reference.
In the earlier releases, the GGSN was encoding ASCII format of the NSAPI in decimal format. NSAPI values of 0 to 9 were encoded in single byte, but values above 10 were encoded as 2 bytes, which lead to faulty message in the OCS.
Now the ASCII format of the NSAPI is encoded in hexadecimal format to restrict the values to one byte.
For example, earlier the value of 10 was encoded as 0x30 0x31 in the byte stream. Now it is encoded as 0x41 in byte stream representing the hexadecimal value A.
Also new in this release, a menu-driven installation management interface with quick, simple menu selections for installation, uninstallation, and upgrade processes. For details, refer to the GTPP Storage Server Installation and Administration Guide.
In Release 8.0, GTPP Storage Server (GSS) extends its support to include Serving GPRS Support Nodes (SGSNs), as well as Gateway GPRS Support Nodes (GGSNs), as sources of CDRs to be preserved and managed.
The custom4 format was created to support writing CDRs in blocks with the FileGen utility. This file format is similar to custom3 file format except CDRs will be written in 2kbyte blocks in a file.
|
l
|
Header: No Header
|
|
l
|
|
l
|
EoF marker: No EoF marker
|
|
l
|
This file format is similar to custom3 file format except that the sequence number for CDR file name is of six digits in length ranging from 000001 to 999999.
|
l
|
This customer-specific file format contains CDRs converted from ASN.1 format to ASCII format according to the following conventions. Each line in the file consists of one CDR which contains 33 parameters occupying 491 bytes.
|
l
|
IMPORTANT: The custom7 file format is customer-specific. For more information on this file format, contact your local sales representative.In this release, the archive mode functionality is enabled by default during GSS installation without requiring user’s input. The default activation is due to the removal of support for non-archive mode.
In this release, the GTPP Storage Server (GSS) extends its support to include custom12 through custom20 in the GTPP custom dictionaries.
Enables use of single mobility core network for provisioning of IPv6 and IPv4 Mobile IP access services. Mitigates IPv4 address depletion concerns for address intensive always-on applications and interactive applications such as VoIP, video telephony and Push-to-Talk (PTT).
MIPv6 allows a user to maintain a persistent IPv6 address even when handing off between Access Service Networks (ASN's) connected to different ASN GW's and allows the access device to be reachable via the same MIPv6 Home of Address (HoA) irrespective of the current point of attachment. A Mobile IPv6 Node (MN) uses two IPv6 addresses:
|
l
|
Care of Address (CoA) derived from Interface-ID assigned by DHCP Proxy component on ASN GW after verification of user or device credentials during network access
|
|
l
|
Home of Address (HoA) assigned by HA during the Mobile IP registration with home network. The MN registers its current point of attachment by providing its CoA.
|
|
l
|
Bidirectional tunnel - In this mode, all data traffic originating from or destined to the MNs MIPv6 HoA is tunneled via the HA.
|
|
l
|
Route optimization - In this mode, the MN informs its correspondent node of its current point of attachment, allowing the correspondent node to directly route packets destined to the MN's HoA through its CoA. Route optimization will not be supported in this release.
|
|
l
|
MN-NAI mobility option in binding messages as per RFC 4283. The MN-NAI option must be included in all Binding messages (Eg initial registration and subsequent updates).
|
From Release 7.1, this feature provides the seamless session mobility for WiMAX subscriber and other access technology subscribers; i.e. 3GPP2. By implementation of this feature HA can be configured for:
The above configurations provide the session continuity capability that enables a dual mode device (a multi radio device) to continue its active data session as it changes its active network attachment from 3GPP2 to Wimax and vice versa with no perceived user impacts from a user experience perspective. This capability brings the following benefits:
Beginning with the 8.1 release of 01/01/09, PDIF supports congestion control and overload disconnect.
Refer to the “Congestion Control” chapter in the PDIF Administration Guide, and to the Command Line Interface Reference Guide for more configuration information
During IKEv2 session setup, MS may or may not include INTERNAL_IP4_DNS in the Config Payload (CP). PDIF may obtain one or more DNS addresses for the subscriber in DNS NVSE from a proxy-MIP Registration Reply message. If Multiple Authentication is used, these DNS addresses may be also received in Diameter AVPs during the first authentication phase, or in RADIUS attributes in the Access Accept messages during the second authentication phase.
In normal mode, by default PDIF always returns the DNS address in the config payload in the second authentication phase if one is received from either the configuration or the HA.
Custom mode is a new feature added to the CLI for this release to provide an alternative to the default operation. In custom mode, depending on the number of INTERNAL_IP4_DNS, PDIF supports the variety of behaviors described in the custom-dns handling section in the “Crypto Template Configuration Mode Commands” chapter of the CLI Reference Guide.
The IKEv2 stack currently always inserts a DELETE Payload in an INFORMATIONAL DELETE Response from both the PDIF and the MN (WMN).
This default behavior has been updated to not insert a DELETE Payload when the response is from the PDIF.
IPMS is a licensed feature for PDIF. It provides access to more saved reporting and analysis information. It supports MIBs as they are developed and bulkstats. It must be configured in its own context.
Multiple Authentication is used when setting up a Proxy-Mobile-IP call with PDIF. In Stage One the device is authenticated with an HSS server. In Stage Two, the subscriber is authenticated with a AAA server over a RADIUS interface.
In Stage One, the authentication method must be EAP-AKA. In Stage Two, the authentication must be either MD5 or GTC. If neither MD5 nor GTC is supported, the PDIF can convert these authentication messages and use standard PAP/CHAP authentication instead.
This is fully described in the “PDIF Overview” chapter in the PDIF Administration Guide.
PDIF is now using an online upgrade model called Active-Standby. This requires a license to activate. Two chassis are connected by a redundancy link and Service Redundancy Protocol (SRP) is used over the link to monitor and control chassis state. Both active and standby chassis have SRP-Activated resources defined. Loopback interfaces are used in the example in the Admin Guide.
"SRP-Activated" means that the resource is configured with srp-activate to make the protocol work between the two chassis. These resources are the same between the Active and Standby PDIF. Loop-back IP addresses in Ingress and Egress contexts and IP pools in egress contexts are usually SRP-Activated resources. Only the active chassis enables the SRP-Activated resources.
Online upgrade is discussed in the PDIF Administration Guide.
PDIF supports x.509 certificates. Every certificate has a public key of its own and configuration on a PDIF is done with the public key and a private key. A mechanism has now been added to verify the AUTH payload from PDIF using PDIF’s public key. If there is a mis-match in the keys, you now see the following warning:
Session Recovery is now a licensed feature for PDIF. It is described in the “PDIF Session Recovery” chapter of the Enhanced Features Guide and is also described in the PDIF Admin Guide.
It is activated by the CLI require session recovery in the Global Config mode.
The PDIF can be configured with multiple IPsec traffic classes, each containing up to 128 traffic selectors, which are used during traffic selector negotiation with UEs. Multiple traffic selectors allow the PDIF to direct outbound traffic to selected IP addresses based on the following protocols: IP, TCP, UDP, and ICMP. The PDIF can also direct TCP and UDP traffic to selected IP addresses and port ranges.
For more information, see the chapters “Packet Data Interworking Function Overview” and “Configuration” in the PDIF Administration Guide.
Beginning with Release 8.3, the PDIF includes a selective Diameter Profile Update Request Control feature. For mobile IP calls, this feature allows WiFi data-only sessions to co-exist with VoIP sessions on the PDIF platform.
This feature is used to identify which subscriber sessions need to have the PDIF and the HSS exchange Diameter Profile Update Request (PUR) and Profile Update Answer (PUA) messages, and allows the PDIF to handle the call setup for a data-only client without having to interact with the HSS.
For more information, see the chapter “Packet Data Interworking Function Overview” in the PDIF Administration Guide.
This is an enhanced feature for the 8.0 release and is a traffic rate limiting method similar to the Traffic Policing, but it provides a buffer facility for packets exceeded the configured limit. Once the packet exceeds the data-rate, the packet queued inside the buffer to be delivered at a later time. Requires separate license key.
The bandwidth enforcement can be done in the downlink and the uplink direction independently. If there is no more buffer space available for subscriber data system can be configured to either drop the packets or kept for the next scheduled traffic session.
For more details on configuration of this service, refer Traffic Policing and Shaping chapter in System Enhanced Feature Configuration Guide.
|
l
|
IMPORTANT: The AOL protocol is detected as Oscar.|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
This section provides information for new features (listed alphabetically) in Release 8.0 for the Serving GPRS Support Node (SGSN). Additional information on these features can be found in the SGSN Overview section of the Product Overview, in the SGSN Administration Guide, and in the CLI Reference Guide.
The following limits for releases 8.0, 8.1, and 9.0 have been modified in the Engineer Rules appendix of the SGSN Administration Guide.
|
l
|
Max # of packets buffered -- rules have been clarified:
- Minimum of 2KB/subscriber. - Maximum of 10KB/subscriber -- if buffers are available in the shared pool*. (*SGSN provides a buffer pool of 10M per session manager - buffer to be shared by all subscribers “belonging” to that session manager.) |
The IMEI check procedure is performed to avoid fraudulent usage of mobile equipment. At attach, when a subscriber registers with an SGSN, the SGSN retrieves the MS equipment identity and then sends a “Check_IMEI” request to the EIR.
The EIR maintains a database of all equipment. The database is organized in three lists – white, gray, and black lists. The EIR checks the three lists to determine on which list the MS’ equipment identity belongs. Then the EIR returns the status request back to the SGSN with the list information.
|
l
|
|
l
|
If the equipment status is gray-listed, the default handling is to allow the registration, which can be overridden via the SGSN CLI.
|
The number of IMEI checks is configured with the check-imei-every-n-events keyword of the equipment-identity-register command in the MAP Service configuration mode. The feature is enabled with the verify-equipment-identity keyword of the gmm retrieve-equipment-identity imei command in the SGSN Operator Policy configuration mode. See the appropriate configuration mode chapters in the CLI Reference Guide for details.
The SGSN Operator Policy now provides a mechanism to configure selective re-authentication and / or P-TMSI re-allocation for 3G events, where an event is one of the following: an attach request, a RAU, a service request, an activate primary PDP context request, a detach request. The N frequency range is 1 to 16. Configuration means that N minus 1 events are skipped before authentication occurs. For configuration details, see the authenticate command in the SGSN Operator Policy Configuration Mode chapter of the CLI Reference Guide.
Within the same chassis, the SGSN can simultaneously operate as both a 2.5G SGSN and a 3G SGSN. This co-location has been done without proprietary protocols thus avoiding problems with mobility and handoff. Dual access provides a range of benefits, such as: use of the same hardware, load sharing, and the need for fewer IP addresses.
It is unlikely that the SGSN would become a bottleneck because of the SGSN’s high signaling rates. However, other nodes in the network may not scale commensurately. To provide network overload protection, the SGSN provides a mechanism to control the number of attaches occurring through it on a per second basis.
The SGSN, using the Channelized Line Cards, now supports fractional E1/DS1 with up to 8 configurable groupings of timeslots per port. This feature is configured with a combination of the path and frame-relay commands in the Channelized Port Configuration Mode chapters of the CLI Reference Guide.
In accordance with RANAP standards, the Signaling Indication IE is only included in RANAP messages RANAP (RAB Assignment Request and/or the Relocation Request messages) when the traffic class is "interactive".
The Command Line Interface (CLI) has been modified to enable the operator to control whether the IE is included if both of the following conditions are met:
2. Signaling Indication IE is included in the current QoS and the value is optimized (value of "1").
New CLI commands have been added to the Radio-Network-Controller configuration mode to govern the inclusion of the Signaling Indication IE in RANAP messages. Refer to the Command Line Interface Reference for information on enabling/disabling this feature.
The SGSN now supports the Ga interface to the CGF for accounting purposes. The SGSN uses the Ga interface to communicate with the charging gateway function (CGF) or the GTPP Storage Server (GSS) using GTP Prime (GTPP). The charging gateway is responsible for buffering and pre-processing billing records. One or more Ga interfaces can be configured per system context. This interface is supported through the following commands in the Context configuration Mode:
The SGSN, with its high capacity, signaling performance, and peering capabilities combined with its level of fault tolerance, delivers many of the benefits of Flex functionary even without deploying SGSN pooling.
As defined by 3GPP TS 23.236, the SGSN implements Gb-Flex functionality to ensure SGSN pooling for 2.5G accesses as both separate pools and as dual-access pools. SGSN pooling enables the following:
|
l
|
Reduces the need/frequency for inter-SGSN RAUs. This substantially reduces signaling load and data transfer delays.
|
In Release 8.0, the SGSN now supports the Gs interface to the MSC/VLR. This interface is vital in the call-setup process as these databases provide authentication information about MS/UEs attempting to attach.
The Gs Service Configuration Mode has been added to configure and manage the Gs interface between the SGSN and the MSC/VLR. This new mode includes the following commands:
- associate-sccp-network
- bssap+
- default
- end
- exit
- max-retransmission
- non-pool-area
- pool-area
- timeout
- vlr
- bssap+
- default
- end
- exit
- max-retransmission
- non-pool-area
- pool-area
- timeout
- vlr
The new commands will be found the chapter titled Gs Service Configuration Mode Commands in the Command Line Interface Reference.
A new command has been created to enable the operator to further control message length by configuring the number of IuConIDs sent in each SGSN Init Reset Resource message.
This change will have no impact on current or future configurations as the previously coded system value was 250.
Refer to the RNC Configuration Mode chapter of the Command Line Interface Reference for additional information.
The SGSN can now be configured to cap the QoS bit rate parameter when the subscribed QoS provided by the HLR is lower than the locally configured value.
Depending upon the keywords included in the command, the SGSN can: take the QoS parameter configuration from the HLR configuration. take the QoS parameter configuration from the local settings for use in the APN policy. during session establishment, apply the lower of either the HLR subscription or the locally configured values.
Refer to the SGSN APN Policy Configuration Mode chapter of the Command Line Interface Reference for the qos command.
SGSN now supports standards compliant network-initiated PDP context activation. The network, or actually the GGSN, is not actually initiating the PDP context activation - it is requesting the MS/UE to activate the PDP context.
The SGSN now offers QoS traffic policing which enables the operator to configure and enforce bandwidth limitations on individual PDP contexts of a particular traffic class. Traffic policing typically deals with eliminating bursts of traffic and managing a traffic flow in order to comply with a traffic contract.
The SGSN conforms to the DiffServ model for QoS by handling the 3GPP defined classes of traffic, QoS negotiation, DSCP marking, traffic policing, and support for HSDPA/HSUPA.
The SGSN can police uplink and downlink traffic according to predefined QoS negotiated limits fixed on the basis of individual contexts - either primary or secondary. The SGSN employs the Two Rate Three Color Marker (RFC2698) algorithm for traffic policing.
For more information, see the SGSN Overview in the Product Overview and the Traffic Policing and Shaping and Dynamic QoS Renegotiation chapter in System Enhanced Feature Configuration Guide.
The session recovery feature, now available for both 2G and 3G SGSNs, handles SGSN services for all attached and/or activated subscribers. When enabled, session recovery provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system preventing a fully connected user session from being disconnected.
This is an enhanced feature and requires a separate license key to be enabled with the SGSN service. For more information on session recovery, refer to the System Enhanced Feature Configuration Guide.
The SGSN implements a configurable short message service (SMS) to send and receive text messages up to 140 octets in length. The SGSN handles multiple, simultaneous messages of both types: those sent from the MS/UE (SMS-MO: mobile originating) and those sent to the MS/UE (SMS-MT: mobile terminating).
After verifying a subscription for the PLMN’s SMS service, the SGSN connects with the SMSC (short message service center), via a Gd interface, to relay received messages (from a mobile) using MAP-MO-FORWARD-REQUESTs for store-and-forward. In the reverse, the SGSN awaits messages from the SMSC via MAP-MT-FORWARD-REQUESTs and checks the subscriber state before relaying them to the target MS/UE. The SGSN will employ both the Page procedure and MNRG (mobile not reachable for GPRS) flags in an attempt to deliver messages to subscribers that are absent.
The SGSN supports both charging for SMS messages (MO - mobile originating and MT - mobile terminating) and lawful intercept of SMS-MO and SMS-MT messages.
Configuration for the service is explained in the SGSN Administration Guide. The various CLI used to enable and configure the SMS service are defined in the Command Line Interface Reference.
|
l
|
SMS is enabled with the short-message-service command in the MAP Service configuration mode. Entering this command accesses the SMS Service configuration mode with the commands to define the SMS service operational configuration:
|
[cntxt_name]st40(config-map-service-serv_name)# short-message-service
[cntxt_name]st40(config-map-service-serv_name-sms-service)#
[cntxt_name]st40(config-map-service-serv_name-sms-service)#
Configurable control of data rates on a per RNC basis enables operators to allow subscribers to roam in and out of coverages areas with different QoS levels.
The SGSN can now limit data rates (via QoS) on a per-RNC basis. Some RNCs support HSPA rates (up to 16 Mbps in the downlink and 8 Mbps in the uplink) and cannot support higher data rates - such as those enabled by HSPA+ (theoretically, up to 256 Mbps both downlink and uplink). Being able to specify the QoS individually for each RNC makes it possible for operators to allow their subscribers to move in-and-out of coverage areas with different QoS levels, such as those based on 3GPP Release 6 (HSPA) and 3GPP Release 7 (HSPA+).
For example, when a PDP established on an RNC with 21 Mbps is handed off to an RNC supporting only 16 Mbps, the end-to-end QoS will be re-negotiated to 16 Mbps. Note that an MS/UE may choose to drop the PDP during the QoS renegotiation to a lower value.
This data rate management per RNC functionality is enabled, in the RNC configuration mode, by specifying the type of 3GPP release specific compliance, either release 7 for HSPA+ rate or pre-release 7 for HSPA rates. For configuration details, refer to the RNC Configuration Mode chapter in the Command Line Interface Reference (version 8.x).
Usage of the GPRS encryption algorithm (GEA) significantly affects the SGSN processing capacity depending upon the GEAx level used - GEA1, GEA2, or GEA3.
Operators could use a mechanism that would enable them to identify the percentages of their customer base that are using the various GEA encryption algorithms. The same tool would also track the migration trend from GEA2 to GEA3 and allow an operator to forecast the need for additional SGSN capacity to exceed.
Enhanced counters should display the absolute number of attached subscribers using each of the GEA algorithms.
Counters have been added to the output of the show sub gprs-only summary CLI command to track:
New counters display the number of subscribers whose MS network capability supports GEA0/- GEA1/GEA2/GEA3. Similarly, the new counters under "Negotiated" indicate the number of subscribers who have negotiated with the SGSN to use a specific encryption algorithm according to the ciphering priority configuration and the network capability.
Operators can configure a “default APN” for subscribers not provisioned in the HLR. This feature is available in releases 8.1 and higher.
The Default APN feature will be used in error situations when the SGSN cannot select a valid APN via the normal APN selection process. Within an operator policy, a default APN can be configured for the SGSN to: override a requested APN when the HLR does not have the requested APN in the subscription profile. provide a viable APN if APN selection fails because there was no "requested APN" and wildcard subscription was not an option.
In either of these instances, the SGSN can provide the default APN as an alternate behavior to ensure that PDP context activation is successful.
Refer to the SGSN Operator Policy Configuration Mode in the Command Line Interface Reference for the command to configure this feature.
In accordance with standards, one tunnel functionality enables the SGSN to establish a direct tunnel at the user plane level - a GTP-U tunnel, directly between the RAN and the GGSN.
The SGSN typically establishes a direct tunnel at PDP context activation using an update PDP context request towards the GGSN.
In effect, a direct tunnel reduces data plane latency as the tunnel functionality acts to remove the SGSN from the data plane and limit the SGSN to the control plane for processing. This improves the user experience (e.g., expedites web page delivery, reduces round trip delay for conversational services). Additionally, direct tunnel functionality implements the standard “SGSN optimization” to improve the usage of user plane resources (and hardware) by removing the requirement from the SGSN to handle the user plane processing.
Direct tunnel means a significant increase in control plane load on both the SGSN and GGSN components of the packet core. Hence, deployment requires highly scalable GGSNs since the volume and frequency of update PDP context messages to the GGSN will increase substantially. Platform capabilities ensure control plane capacity will not be a limiting factor with direct tunnel deployment.
For more information on Direct Tunnel configuration, refer to SGSN Direct Tunnel Configuration chapter in System Enhanced Feature Configuration Guide.
In accordance with RANAP standards, the Signaling Indication IE is only included in RANAP messages RANAP (RAB Assignment Request and/or the Relocation Request messages) when the traffic class is "interactive".
The Command Line Interface (CLI) has been modified to enable the operator to control whether the IE is included if both of the following conditions are met:
New CLI commands have been added to the RNC configuration mode to govern the inclusion of the Signaling Indication IE in RANAP messages. Refer to the Command Line Interface Reference for information on enabling/disabling this feature.
It is now possible to configure the transport layer from the standard UPD to TCP. This functionality has been added to enable the carrier to select connection-oriented sessions for the Ga interface. For more information, refer to the gtpp transport-layer command in the GTPP Group Configuration Mode chapter of the Command Line Interface Reference.
A hard disk has been introduced in the ST40 platform to add storage capability. When storing CDR files on the SMC hard disk, first they are stored on RAMFS before they are moved to the hard disk and then they can be off-loaded via ftp or sftp to an external server (such as the L-ESS or the GSS) or billing system. For additional support information, see Hard Disk Support on SMC Card in ST40 Platform.
|
l
|
Use the new command gtpp storage-server local file {local | remote } command in GTPP Group Configuration Mode to configure and enable hard disk usage.
|
|
l
|
Use the new show/clear commands { show | clear } gtpp storage-server local file { counter | statistics } in the Exec Mode to monitor/clear the file counters and statistics on the hard disk.
|
|
l
|
Use the new gtpp ram-disk-limit and gtpp compression-process commands in the Global Configuration Mode to allocate RAM for files and the number of compression process to support the hard disk functionality.
|
The SGSN supports 2G Gb Flex with SGSN Pooling and now 3G Iu Flex with SGSN Pooling as an orderable feature.
Iu Flex and SGSN Pooling functionality has been implemented according to 3GPP TS23.236. The SGSN supports pooling for both 3G and 2G accesses, both as separate pools and as dual-access pools.
IuFlex works by defining NRIs in the SGSN service and configuring RNCs as pooled. Pooled RNCs will be able to co-exist with RNCs that are connected to only one SGSN.
Iu Flex offloading is also enabled via configuration. This implementation allows carriers to load balance sessions among pooled SGSNs; where Iu Flex provides carriers deterministic failure recovery.
|
l
|
Reduces signaling load as well as data transfer due to conversion of inter-SGSN RAUs to intra-SGSN RAUs for moves between RAs controlled by the same pool.
|
|
l
|
Simplifies introduction of new nodes and replacement of old nodes as subscribers can be moved in a planned manner to new nodes.
|
A new command has been created to enable the operator to further control message length by configuring the number of IuConIDs sent in each SGSN Init Reset Resource message.
This change will have no impact on current or future configurations as the previously coded system value was 250.
Refer to the RNC Configuration Mode chapter of the Command Line Interface Reference for additional information.
The SGSN can now be configured to cap the QoS bit rate parameter when the subscribed QoS provided by the HLR is lower than the locally configured value.
Depending upon the keywords included in the command, the SGSN can: take the QoS parameter configuration from the HLR configuration. take the QoS parameter configuration from the local settings for use in the APN policy. during session establishment, apply the lower of either the HLR subscription or the locally configured values.
Refer to the SGSN APN Policy Configuration Mode chapter of the Command Line Interface Reference for the qos command.
With this new feature, the 2.5G SGSN supports cell-sites with more than one PLMN-ID. Operators can now assign a different PLMN-ID to each cell in the network (typically, there are no more than 3 or 4 PLMN-IDs in a single network). This multiple PLMN support also enables an operator to 'hire out' their infrastructure to other operators who wish to use their own PLMN-IDs. Each cell can be part of only one PLMN (one GRPS service). By configuring the GPRS service for each PLMN-ID, this feature allows the 2.5G SGSN to perform handovers between the service instances.
The 2.5G SGSN supports MS handover from one PLMN to another PLMN by configuring multiple instances of the GPRS service, each with a different PLMN-ID, in the same context. Each of the GPRS services must use the same MAP, SGTPU and GS services so these only need to be defined one-time per context. For command details, refer to the GPRS Service Configuration Mode and MAP, SGTP, and GS Service Configuration Mode chapters in the Command Line Interface Reference.
To enable appropriate S-CDR generation in a multiple PLMN-ID scenario, use the plmn-id-change keyword for the gtpp trigger command in the GTPP Group Configuration Mode also documented in the CLI Reference.
The SGSN enables two or more network operators to share common network infrastructure. In accordance with 3GPP TS 23.251, the SGSN supports two different configurations for network sharing based on the resources being shared: gateway core network (GWCN) and multi-operator core network (MOCN).
With GWCN, the complete radio access network and partial core network are shared among different operators. Each operator will have its own network node for GGSN/HLR, etc., while sharing SGSN/MSC and the remaining radio network.
With MOCN, the complete radio network is shared among different operators, while each operator maintains its own separate core network.
With these two configurations, the SGSN supports multiple scenarios such as MOCN with non-supporting UE, MOCN with supporting UE, GWCN with supporting UE, and GWCN with non-supporting UE.
The NPU FastPath feature is proprietary and only available on the ST40 SGSN systems. The purpose of this type of internal direct tunnel is to optimize resource usage and reduce latency when processing GTP-U packets. Incoming traffic passes through the switch fabric and the routing headers are changed to re-route traffic from the incoming network processing unit (NPU) of the ingress PSC directly to the outgoing NPU of the egress PSC. This means that intervening NPUs and CPUs are by-passed. This provides the SGSN with router-like latency and increased node signaling capacity.
Fast path is established when both ends of a tunnel are available. Two fast path flows are established, one for the uplink and one for the downlink direction for a given PDP context.
If FastPath cannot be established, the NPU forwards the GTP-U packets to a CPU for processing and they are processed like all other packets.
The SGSN now supports the four-port gigabit-Ethernet line card - QGLC. This card will enable the SGSN to utilize standard-compliant link aggregation. For additional feature information, see QGLC and Link Aggregation feature descriptions in the Common Features in Release 8.0 section of this chapter.
For details about this new line card, see the Hardware Platform Overview chapter of the Hardware Installation and Administration Guide.
Usage of the GPRS encryption algorithm (GEA) significantly affects the SGSN processing capacity depending upon the GEAx level used - GEA1, GEA2, or GEA3.
Operators could use a mechanism that would enable them to identify the percentages of their customer base that are using the various GEA encryption algorithms. The same tool would also track the migration trend from GEA2 to GEA3 and allow an operator to forecast the need for additional SGSN capacity to exceed.
Enhanced counters should display the absolute number of attached subscribers using each of the GEA algorithms.
Counters have been added to the output of the show sub gprs-only summary CLI command to track:
New counters display the number of subscribers whose MS network capability supports GEA0/GEA1/GEA2/GEA3. Similarly, the new counters under "Negotiated" indicate the number of subscribers who have negotiated with the SGSN to use a specific encryption algorithm according to the ciphering priority configuration and the network capability.
The SGSN now enables setting the priority of service via the configuration of the allocation/retention priority (ARP) IE. By including this IE in the RANAP message during the RAB assignment procedure it is possible to specify the relative importance of the radio access bearers for the allocation and retention of traffic. When there is a resource crunch, the IE is used by the RNC to allocate or deallocate resources according to the defined priority. This IE also tells whether queuing of packets is allowed or not.
Although the HLR subscription record only provides a single priority parameter (values 0 to 3), the RNC needs additional information, which our configuration command maps to the subscription priority. Additional information needed:
For Frame Relay signaling, the SGSN now supports the Channelized Line Card 2 (CLC2), the next-generation SONET/SDH channelized line card for the ST40. In North America, the card supplies ANSI SONET STS-3 (optical OC-3) signaling. In Europe, the card supplies SDH STM-1 (optical OC-3). The transmission rate for the card is 155.52 Mb/s with 336 SONET channels supplying T1 and 252 SDH channels supplying E1. The CLC2 is RoHs 6/6 compliant. Each CLC2 provides four optical fiber physical interfaces (ports). For more information about this card, refer to the ST40 Hardware Installation and Administration Guide.
For ATM signaling, the SGSN now supports the Optical Line Card 2 (CLC2), the next-generation SONET/SDH optical line card for ATM signaling on the ST40. The OLC2 supports all features, including 4 ports, available on the original OLC but now includes RoHs 6/6 compliance. For more information about this card, refer to the ST40 Hardware Installation and Administration Guide.
This section provides information for new features for the Web Element Manager application in Release 8.0.
Support for Configurable DSCP Marking Based on Allocation/Retention Priority
GGSN now supports configurable DSCP marking based on traffic handling priority and allocation/retention priority for the Interactive Traffic class. A DSCP value matrix is introduced and used to map based on these priorities only if the allocation priority is present in the QOS profile.
Click Configuration | GGSN | GGSN Service | Add / Modify GGSN Service Configuration Dialog Box - Timers/QoS tab.
Click Configuration | GGSN | APN | APN Configuration Dialog Box - Tunnel / Qos tab.
WEM now provides support for SGSN bulk statistics. Multiple bulk statistic counters are introduced and grouped according to the following SGSN schemas:
|
l
|
SGSN Schema: These are variables per SGSN service and uniquely identified by SGSN service name and VPN context.
|
|
l
|
SCCP Schema: Each SCCP network is uniquely identified by a number in the chassis. All the statistics in this schema are per sccp-network.
|
|
l
|
SGTP Schema: These are variables per SGTP service and identified uniquely by SGTP service name and VPN context.
|
|
l
|
SS7RD Schema: Each SS7-routing domain is identified by a number unique across the chassis. All the statistics in this schema are per ss7rd.
|
Click Accounting | Content Filtering | Report Configuration.
Click Accounting | Content Filtering | View Reports.
This functionality provides the various configurables to configure PDIF and obtain the PDIF bulkstats.
Click Configuration | PDIF | PDIF Service | Add/Modify PDIF Service Dialog Box – General / AAA/HSS tab.
Click Performance | PDIF | PDIF Statistics Dialog Box.
Click Configuration | Context Provisioning | IP Security | IKEv2 IKESA Transform Set | IKEv2 IKESA Transform Set Configuration Dialog Box.
Click Configuration | Context Provisioning | IP Security | IKEv2 IKESA Transform Set | Add/Modify IKEv2 IKESA Transform Set Dialog Box.
Click Configuration | Context Provisioning | IP Security | IKEv2 IPSEC Transform Set | IKEv2 IPSEC Transform Set Configuration Dialog Box.
Click Configuration | Context Provisioning | IP Security | IKEv2 IPSEC Transform Set | Add/Modify IKEv2 IPSEC Transform Set Dialog Box.
WEM provides PDIF support for the crypto template. The Crypto Template Configuration Mode is used to configure an IKEv2 PDIF IPSec policy. A PDIF service will not function without a configured crypto template. Only one crypto template can be configured per PDIF service.
The Crypto Template Payload Configuration Mode is used to assign the correct IPSec transform set from a list of up to four different transform sets, and to assign Mobile IP addresses.
Click Configuration | Context Provisioning | IP Security | Crypto Template | Crypto Template Configuration Dialog Box - General / IKEv2 IKESA/Authentication / Payload tab.
Click Configuration | Context Provisioning | IP Security | Add/Modify Crypto Template | Crypto Template Configuration Dialog Box - General / IKEv2 IKESA/Authentication / Payload tab.
Click Configuration | Context Provisioning | IPv6 Neighbors | IPv6 Neighbor Configuration Dialog Box.
Click Performance | IPv6 Interface Summary | IPv6 Interface Summary Dialog Box.
WEM provides PDIF support to configure the Diameter Endpoint and Diameter Authentication configuration.
The Network Audit Tool in WEM supports the on demand or periodic auditing of IMG configuration attributes (audit attributes) such as PPP MRU, Auth Sequence, Bulkstats Schema Needs Update, etc.
IP Multipathing is a feature supported on Sun® Solaris® provided by Sun Microsystems. With IPMP, two or more NICs are dedicated for each network to which the host connects. Each interface is assigned a static “test” IP address, which is used to access the operational state of the interface. Each virtual IP address is assigned to an interface, though there may be more interfaces than virtual IP addresses, some of the interfaces being purely for standby purposes. When the failure of an interface is detected its virtual IP addresses are swapped to an operational interface in the group.
IMPORTANT: IPMP is a feature supported on Sun® Solaris® provided by Sun Microsystems. The configuration is included in Section VI of the System Administration Guide: IP Services from Sun Microsystems. For more information, refer to the Sun documentationFor more information on configuration of this feature on WEM Servers, refer WEM Installation and Administration Guide.
